点击阅读原文(14年的文章)
简单来说,web服务器提供页面给浏览器,而app服务器提供客户端可以调用的接口.
web服务器处理HTTP请求,而app服务器基于多种不同的协议,处理应用程序的逻辑问题.
##Web服务器##
web服务器处理HTTP协议。当收到一个HTTP请求之后，web服务器会返回一个HTTP响应，比如一个HTML页面。为了处理请求，它可能响应一个静态的HTML页面、图片、重定向，或者代理（delegate）其他动态响应。这些动态响应可以由其他程序生成，包括CGI脚本，JSPs，servlets，ASPs，服务器端的Javascript，或者其他服务器端技术。而这些服务器端程序响应，大多数时候都表现为HTML页面，供浏览器访问。
理解一个web服务器的代理模型(delegate model)相对比较简单。当web服务器接收到一个请求，它只是简单的将请求交给处理该请求的最优程序。除了为服务器程序简单的提供一个运行环境（服务器程序可以在其中运行，并且返回生成的响应）之外，web服务器不提供任何功能。服务器程序一般自己处理交换(transaction)、数据库连接、消息分发等。
虽然web服务器不提供以上的服务，但是它一般会提供诸如容错机制，负载均衡、缓存、集群等的可扩展性。而后者，一般来说不应该部署在web服务器上，而应该在app服务器上！
App服务器
根据我们的定义，app服务器可以基于各种不同的协议（可能包含HTTP协议），为客户端程序提供应用逻辑的处理。不同于web服务器主要发送用来展示在浏览器上的HTML页面，app服务器为客户端程序处理应用逻辑方面问题。应用程序使用这些逻辑，就如同调用一个对象的方法（或者面向过程编程中的函数）一样简单。
这些应用程序可能包含PC机上运行的GUI进程，web服务器，甚至其他的app服务器。app服务器和客户端之间的通信并不局限于简单的显示标记，而是可以由程序逻辑，比如数据表单、方法调用，而非静态的HTML，这样，客户端程序就可以按需去用了！
在大多数情况下，app服务器通过元件API，比如基于j2ee app服务器的EJB，来提供应用逻辑。而更多的情况下，app服务器自己管理自己的资源。这些责任（gate-keeping）包括安全、进程交互、资源池、消息分发等。同web服务器一样，app服务器也可能需要各种可扩展性和容错机制。
举例
以一个提供实时价格和相关信息的在线商店为例，它极有可能提供了一个表单，用户可以选择不同的产品并查询。它会查找，并通过HTML网页展示结果。这个网站可能有多种方式来实现这个功能，下面我们将举两个相反的例子，一个不使用app服务器，而另一个使用。通过这两个例子，可以帮助你理解app服务器的功能。
场景1：web服务器，而非app服务器
在这个场景里，web服务器独自提供在线商店的功能。它接受用户的请求，交给服务器端程序处理。该服务器端程序通过数据库，或者纯文本，查找到价格信息，然后生成HTML响应，通过web服务器返回给用户的浏览器。
总结来说，web服务器仅需要接受HTTP请求，并响应HTML网页。
场景2： web服务器 + app服务器
同场景1一样，web服务器仍然代理脚本生成的响应。但是你可以把业务逻辑部署在app服务器上。这样，脚本就不需要去关注怎样查询和生成响应，而仅需要调用app服务器提供查询服务，从而利用其生成它的HTML响应。
在这个例子中，app服务器提供了价格查询的业务逻辑。这个逻辑不应该包含怎样去展示，或者强迫客户端使用这些数据。相反的是，客户端和app服务器进行交互，只有当客户端调用了app服务器的价格查询服务的时候，该服务才查找到信息并返回。
同HTML代码生成分离开后，价格查询逻辑的复用性提高了。另外一个客户端，比如收银机，同样可以调用这个接口。而场景1里，价格查询服务就很难被重用，因为它和HTML页面紧密联系。
总结来说，第二个场景中，web服务器处理HTTP请求，并返回HTML页面，而app服务器处理业务逻辑。
注意
近来，XML web服务器模糊了app服务器和web服务器的界限。发送一个XML请求给web服务器，web服务器可以像过去的app服务器一样，处理数据并返回响应。
另外，很多app服务器包含web服务器，这就意味着你可以把web服务器看做app服务器的一个子集。虽然app服务器包含web服务器的功能，但是开发者还是很少以此身份发布app服务器。如果需要的话，他们通常将web服务器和app服务器分离开。这样的目的是，性能（简单的web请求不会影响到app服务器的性能）、发布配置（专用的web服务器，集群等）、更好的厂商选择.
